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FIG. 6 illustrates a method of distributing and federating metadata 
across a distributed network according to an embodiment of the invention. 
FIG. 6 is divided into Figures 6-A and 6-B for convenience. 



Please replace the paragraph beginning at page 8, line 6, and ending at line 8, 
with the following rewritten paragraph: 



^ FIG. 18 is an activity diagram depicting the flow of events involved 

IV 

in utilizing a push agent to send data to the server in one embodiment of 
the invention. FIG. 18 is divided into Figures 18-A through 18-C for 
convenience. 



Please replace the paragraph beginning at page 8, line 15, and ending at line 18, 
with the following rewritten paragraph: 



FIG. 22 is a block diagram, which illustrates the structure used and 
method for analyzing patient demographic data and correlating it against 
existing information to create or update a universal person object 
according to one embodiment of the invention. 



Please replace the six paragraphs beginning at page 9, line 1, and ending at line 
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17, with the following rewritten paragraphs: 



FIG. 24 provides an XML document type definition (DTD) used to 
describe the message envelope and the payload containers transmitted to 
the system in the write metadata transaction. FIG. 24 is divided into 
Figures 24-A and 24-B for convenience. 

FIG. 25 provides the XML DTD used to describe the data 
transmitted in the write metadata transaction. FIG. 25 is divided into 
Figures 25-A through 25-J for convenience. 

FIG. 26 provides the XML DTD used to describe the data 
transmitted in delete metadata transaction according to one embodiment 
of the invention. FIG. 26 is divided into Figures 26-A through 26-F for 
convenience. 

FIG. 27 provides the XML DTD used to describe the data 
transmitted in merge metadata transaction according to one embodiment 
of the invention. FIG. 27 is divided into Figures 27-A through 27-J for 
convenience. 
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FIG. 28 illustrates the class hierarchy for a universal person object 
for identifying and finding patients, their providers and the organizations 
that have provided treatment according to one embodiment of the 
invention. FIG. 28 is divided into Figures 28-A and 28-B for convenience. 

FIG. 29 is a detailed sequence diagram showing how queries are 
processed according to one embodiment of the invention. FIG. 29 is 
divided into Figures 29-A and 29-B for convenience. 



Please replace the paragraph beginning at page 26, line 7, and ending at line 16, 
with the following rewritten paragraph: 



FIG. 6 extends the functionality described above to allow federation 
of identifiers across multiple domains. FIG. 6 is divided into Figures 6-A 
and 6-B for convenience. In this schema, a local exchange server, 604, 
^7 correlates patients across a number of systems within a local domain. At 
step 1 information is sent to the local server by a clinical system such as a 
pharmacy system, 601 , a laboratory system, 602, or a radiology system, 
603. A local universal person object is created and then forwarded to the 
parent, the domain exchange server, 606, in its hierarchy. The parent can 
receive data from multiple local exchange servers such as shown at 605. 



DURI\295323_2 



-4- 





Icket No. 019157-000020 
Serial No. 09/770,166 



The parent now knows that it can query local exchange server 604 at step 
2 and ask for information about a patient and the local exchange server 
will subsequently query each of its subsystems to find records for the 
patient. 



Please replace the paragraph beginning at page 38, line 3, and ending at line 12, 
with the following rewritten paragraph: 



Figures 18-A, 18-B and 18-C for convenience. The last horizontal line on 
FIG. 18-A is the same line as the first horizontal line on FIG. 18-B, and the 



last horizontal line on FIG. 18-B is the same line as the first horizontal line 
on FIG. 18-C. By "external clinical system" we mean a system used by a 
health care provider that is supplying data to the exchange system. The 
external system can also be one that requests data from the exchange. 
This example demonstrates the method by which the data would be sent 
to the exchange. The example illustrates the loosely coupled nature of 
the exchange architecture. Loosely coupled systems do not have hard 
coded linkages between them, but rely instead on a communications 
protocols and standards to achieve their associations. 



FIG. 18 is a sequence diagram describing how an external clinical 



system requests service from the exchange. FIG. 18 is divided into 
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Please replace the five paragraphs beginning at page 48, line 1 , and ending at 
line 20, with the following rewritten paragraphs: 



FIG. 24 provides an example XML document type definition (DTD). 
This DTD is used to describe the message envelope and the payload 
containers transmitted to the system in a "write metadata" transaction. 
FIG. 24 is divided into Figures 24-A and 24-B for convenient viewing. 

FIG. 25 provides an example XML DTD used to describe the data 
transmitted in a "write metadata" transaction. FIG. 25 is divided into 
Figures 25-A through 25-J for convenient viewing. 

FIG. 26 provides an example XML DTD used to describe the data 
transmitted in "delete metadata" transaction. FIG. 26 is divided into 
Figures 26-A through 26-F for convenient viewing. 

FIG. 27 provides an example XML DTD used to describe the data 
transmitted in "merge metadata" transaction. FIG. 27 is divided into 
Figures 27-A through 27-J for convenience. 



DUR1\295323_ 2 



-6- 



n 



Scket No. 019157-000020 
Serial No. 09/770,166 



FIG. 28 illustrates the class hierarchies for the entities associated in 
the exchange server for identifying and finding patients, their providers 
and the organizations that have provided treatment. FIG. 28 is divided 
into Figures 28-A and 28-B for convenience. The last horizontal line on 
FIG. 28-A is the same line as the first horizontal line on FIG. 28-B. This 
hierarchy defines the universal person object that establishes patient 
identity in the exchange. Rather than rely on a generated or artificial 
identifier or key, the exchange relies on the rich set of demographic data 
and history that becomes a universal person object. This class hierarchy 
allows the exchange to capture several complex relationships between a 
person and the many attributes that are a part of the person. 



Please replace the paragraph beginning at page 50, line 5, and ending at line 10, 
with the following rewritten paragraph: 



In addition to the capability to receive patient demographic data or 
locator information, it is necessary to answer queries that will use the 
correlated and processed data. FIG. 29 describes the mechanism for 
processing a query to find where a patient has been seen and what 
records might be available for that patient. FIG. 29 is a sequence diagram 
describing details of how an external clinical system requests a location 
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from the exchange. FIG. 29 is divided into Figures 29-A and 29-B for 
convenience. The last horizontal line on FIG. 29-A is the same line as the 
first horizontal line on FIG. 29-B. 
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